Such a method or automation system is employed in the area of automation technology in which a number of tasks often have to be fulfilled simultaneously. To control complex processes such as the production of automobiles in a plant for example, software systems are used which consist of a number of programs or processes (e.g. production data capture, control of the systems, capture and editing of operating data/statistics etc.). These processes must divide up the available computing power between them or must share the computing power with other systems respectively. The allocation of the computing power to processes is generally undertaken using the priorities of the corresponding processes. In such cases the priorities of the corresponding processes are not to be seen as equal over their entire runtime, but as dependent for example on times of day (typically generating statistics at the end of the shift) or operating states. If these framework conditions change, the priorities of the processes should be adapted accordingly to achieve optimum task processing.
In the multitasking operating systems which are the norm these days (e.g. Windows, Linux) processes are allocated specific time slices for execution of depending on their priority. This means that processes or threads (subunits of processes for parallel execution of different logical program execution parts) to which a high priority has been assigned are given preference for execution whereas on the other hand other waiting processes or threads with lower priority must continue to wait. Processes/threads are assigned a priority either by the operating system by default or programmatically (by the process itself or by another process with corresponding rights), which thus essentially determines the execution sequence of the processes/threads of the system. Depending on priorities allocated to processes, the allocation of computing power is undertaken by the operating system.
In the usual operating systems employed nowadays the priority of processes/threads is the sole decisive factor governing the runtime behavior since the corresponding scheduler of the operating system does not have any additional semantic information about the processes involved or about their tasks which it can use for a decision about the allocation of computing power. Nor can this be expected with multipurpose operating systems, since a generalizing approach must be adopted here. To adapt the runtime behavior of the individual processes to changes in peripheral conditions (peripheral time conditions such as shift end or event-controlled peripheral conditions) there was previously only the option of making priority decisions and changes programmatically within the processes themselves.